The present invention generally relates to ennoversion management systems, and more particularly to an ennoversion management system for a data processing system which regards the real world as an object model, makes the real world correspond to an extension and a connotation, places the connotation in an information concealed region, makes identification information which specifies the connotation correspond to the extension, and describes the real world by a static world and a dynamic world which form an object world in correspondence with the extension. A system mechanism is given to the static world by classes and/or composite classes. The movement in a dynamic model is given to the dynamic world by instances of the classes and/or composite classes. An object identification is added with respect to the individual objects forming each composite object. The composite objects used in the data processing system can be specified by the groups of the object identifications which are added to the individual objects.
First, a description will be given of a conceivable method of forming a capsule of objects, by referring to FIGS. 1A through 1C.
For example, execution process data 214 are made up of a series of instructions (or instruction groups) 250 shown in FIG. 1A which are serialized in the processing sequence. A number of such instructions (or instruction groups) 250 form a processing unit 251 which executes a predetermined process, that is, makes a certain behavior.
Accordingly, the execution process data 214 shown in FIG. 1A may be regarded as a collection of the processing units 251 which are serialized in the processing sequence as shown in FIG. 1B, where each processing unit 251 makes a certain behavior. The serialized execution process data 214 shown in FIG. 1B as a whole carry out a specific operation. Hence, the execution process data 214 for carrying out another specific operation is a connection of the processing units 251 having a different combination.
As the number of existing processing units 251 which make different behaviors becomes large, the individual processing units 251 are integrated under a predetermined method M as shown in FIG. 1C, so as to obtain an integrated processing unit group which carries out the same operation as the execution process data 214 shown in FIG. 1B.
Next, a description will be given of particular examples of the relationships of the object, the object command and the object part.
FIG. 2 shows a real world, that is, an example of a model for departments of a company. Within a box representing "employees" in FIG. 2, there is a "secretary" belonging to a "work type=1", a "leader" belonging to a "work type=2", and a "worker" belonging to a "work type=3". A box representing "employees" belongs to a box representing a "team".
The "leader" is related to the "team" under the relationship "team leader". In addition, the "worker" is related to a "machine" under the relationship "worker/machine" within the box representing "work unit".
The "team" and the "machine" are related under the relationship "machine/workshop". The "worker" and the "machine" are related under the relationship "machine/worker". In addition, the "employee" and the "department/employee" are related under the relationship "department".
Furthermore, the "employee" and the "position" are related under the relationship "employee/attribute". The "work unit" and the "part" are related under the relationship "work unit/part".
The following relationships also exist.
(1) The "department" is related to the object "department name" and the object "dollars".
(2) The "team" is related to the object "name" by a team identification number, related to the object "employee number" by the work type, related to the object "code name" and the object "surname" by the name, related to the object "dollars" by the salary, related to the object "dollars" by the average salary, and related to the object "number" by the average number of departments.
(3) The "secretary" is related to the object "number" by the typing speed.
(4) The "position" is related to the object "name" by the name, and related to the object "year" by the age.
(5) The "part" is related to the object "part number" and the object "dollars".
(6) The "work unit/part" is related to the object "number" by the volume.
(7) The "work unit" is related to the object "time" by the required time.
(8) The "machine" is related to the object "machine number", the object "dollars" and the object "machine name".
(9) The "machine/work" is related to the object "time" by the time used.
The model shown in FIG. 2 can generally be represented as shown in FIG. 3 if the "behavior" (or method) is indicated by a circular box, the "data" is indicated by a rectangular box, and the "relationship" is indicated by a rhombic box. In other words, (1) a method "a" and a data "I" are combined and function as one larger data "IV", (2) methods "b" and "c" are related to a data "II" by a relationship ".alpha." and function as one larger data "V", (3) methods "c" and "d" are related to a data "III" by a relationship ".beta." and function as one larger data "VI", and (4) a method "e" are related to data "IV" and "V" by a relationship ".tau." and function as still a larger data "VII". In other words, the behaviors (or methods) are gathered and represented as a larger group.
Each circular box, rectangular box and rhombic box shown in FIG. 3 can be treated as an individual object.
The forming of a capsule shown in FIG. 4A will now be considered for a collection of the method "a" and the data "I" shown in FIG. 3. In FIG. 4A, an opening is formed at the top of the capsule to indicate that a message communication can be made. If this opening of the capsule were closed as shown on the left side of FIG. 4B, such a capsule would then correspond to the data "IV" which is a collection of the method "a" and the data "I" in FIG. 3. If a composite object is obtained by adding a method "M" to the data "D" (capsule) shown on the left side of FIG. 4B, the data shown at the central part of FIG. 4B is obtained. Further, if a composite object is obtained by further adding a method to the data shown at the central part of FIG. 4B, the data shown on the right side of FIG. 4B is obtained. Hence, FIG. 4B shows the formation of composite objects by successively adding methods.
The formation of the composite objects is not limited to that shown in FIG. 4B. For example, the composite objects may be formed as shown in FIG. 4C. In FIG. 4C, the data "D" of the object shown on the leftmost side is replaced by an object which is made up of a method and a data, as shown on the second leftmost side. In this case, a message passing is required between a method "M1" and a data "D1", and the method "M1" becomes one object as shown on the second rightmost side in FIG. 4C. As a result, objects "A" and "B" exist within an object "C", and the message passing exists between the objects "A" and "B".
Furthermore, if the method "M" of the object "B" is replaced by an object "B1" and the data "D" of the object "B" is replaced by an object "B2", both the object "B1" and "B2" exist within the object "B" and the message passing exists between the objects "B1" and "B2" as shown on the rightmost side in FIG. 4C.
Therefore, the composite objects are formed by successively combining the objects. For example, the so-called primitive objects which will be described later are combined to form a capsule object, the capsule objects are combined to form an event object, and the event objects are combined to form a system object.
The data "D" described above is generally made up of a plurality of processing units which are the subject of the processing. On the other hand, the method "M" may be considered as information or information group instructing how the plurality of processing units are to be utilized. The object which is represented in FIG. 4 is a "processing unit" which is treated as an individual "processing unit" or a collection of "individual processing units".
As shown in FIG. 3, the individual objects "I", "II" and "III" form a part of the larger objects "IV", "V" and "VI". In addition, the objects "IV", "V" and "VI" form a part of still a larger object "VII". In other words, the objects "IV", "V" and "VI" are in an "is-a" relationship or a "part-of" relationship with the object "VII" when viewed from the object "VII".
If the objects "I", "II" and "III" are regarded as minimum units, these objects "I", "II" and "III" may be said to be primitive objects. The capsule object is formed by a collection of such primitive objects. The event object is formed by a collection of such capsule objects. Furthermore, a still larger system object is formed by a collection of such event objects.
The objects described above which are made up of a collection of smaller objects are respectively referred to as a composite object. The primitive object is included in the concept of the composite object. However, the primitive object is an object of the minimum unit as described above. For this reason, when a reference is generally made to a "composite object" or an "object", it is better to exclude the primitive object which exists by itself and cannot be decomposed further.
The object in the capsule form is generally made up of the composite objects described above in the capsule form.
As shown in FIG. 2, the objects corresponding to "processing units" are mutually complicated and related in the real world. The "processing unit" may be the individual processing unit or a collection of individual processing units.
As described above, the real world in general can be described by a model using the objects. Hence, it is desirable to recall the classes and the composite classes held in the information concealed world and to use them for the system design. In addition, when making the system design, it is desirable to use four hierarchical layers made up of the classes, composite classes, instances and composite instances (sessions).
However, according to the generally known program version management, there is no concept of carrying out the version management by making the classes, the composite classes, the instances and the composite instances (sessions) correspond to each other.
On the other hand, according to the conventional version management, the version management is made to manage the state of the program modification. In other words, when an error or some inconvenience exists in the original program and a modification is made, the version management is made to manage the state of this modification.
However, in the data processing system, it is desirable to introduce the concept of obtaining more superior composite classes and composite instances by exceeding the range of the conventional version management when it becomes necessary to partially modify particularly the composite classes and the composite instances so as to match the desired process which is requested by the user.